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Abstract 

Transactional memory promises to make concurrent programming tractable and efficient by 
allowing the user to assemble sequences of actions in atomic transactions with all-or-nothing 
semantics. It is believed that, by its very virtue, transactional memory must ensure that all 
committed transactions constitute a serial execution respecting the real-time order. In contrast, 
aborted or incomplete transactions should not "take effect." But what does "not taking effect" 
mean exactly? 

It seems natural to expect that aborted or incomplete transactions do not appear in the 
global serial execution, and, thus, no committed transaction can be affected by them. We 
introduce another, less obvious, feature of "not taking effect" called non-interference: aborted 
or incomplete transactions should not force any other transaction to abort. More precisely, by 
removing a subset of aborted or incomplete transactions from the history, we should not be 
able to turn an aborted transaction into a committed one. We consider the popular correctness 
criterion of opacity that requires all transactions (be they committed, aborted or incomplete) to 
witness the same global serial execution. We show that non-interference with respect to opacity 
is, in a strict sense, not implementable. 

In contrast, when we only require local correctness, non-interference is implementable. Infor- 
mally, a correctness criterion is local if it only requires that every transaction can be serialized 
along with (a subset of) the transactions committed before its last event (aborted or incomplete 
transactions ignored). We give a few examples of local correctness properties, including the 
recently proposed criterion of virtual world consistency, and present a simple though efficient 
implementation that satisfies non-interference and local opacity. 

1 Introduction 

Transactional memory (TM) promises to make concurrent programming efficient and tractable. 
The programmer simply represents a sequence of instructions that should appear atomic as a 
speculative transaction that may either commit or abort. It is usually expected that a TM serializes 
all committed transactions, i.e., makes them appear as in some sequential execution. An implication 
of this requirement is that no committed transaction can read values written by a transaction that 
is aborted or might abort in the future. Intuitively, this is a desirable property because it does not 
allow a write performed within a transaction to get "visible" as long as there is a chance for the 
transaction to abort. 

But is this all we can do if we do not want aborted or incomplete transactions to "take effect" ? 
We observe that there is a more subtle side of the "taking effect" phenomenon that is usually not 
taken into consideration. An incomplete or aborted transaction may cause another transaction 
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to abort. Suppose we have an execution in which an aborted transaction T cannot be commit- 
ted without violating correctness of the execution, but if we remove some incomplete or aborted 
transactions, then T can be safely committed. We call a TM that never exports such executions 
non-interfering. The non-intereference phenomenon was first highlighted in |11| . 

Thus, ideally, a TM must "insulate" transactions that are aborted or might abort in the future 
from producing any effect, either by affecting reads of other transactions or by provoking forceful 
aborts. 

Non-interference and permissiveness. In this paper, we formally define the notion of non-interference. 
We observe that, when defined with respect to a given correctness criterion C, non-interference pro- 
duces a subset of permissive [3J with respect to C histories. This is not difficult to see if we recall 
that in a permissive (with respect to C) history, no aborted transaction can be turned into a 
committed one while still satisfying C. 

Moreover, when we focus on opaque histories [4j[5], we observe that non-interference gives 
a strict subset of permissive opaque histories. Opacity requires that all transactions (be they 
committed, aborted, or incomplete) constitute a consistent sequential execution in which every read 
returns the latest committed written value. This is a strong requirement, because it expects every 
transaction (even aborted or incomplete) to witness the same sequential execution. Indeed, there 
exist permissive opaque histories that do not provide non-interference: some aborted transactions 
force other transactions to abort. 
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Figure 1: A permissive opaque but not non- interfering history: T2 forces T\ to abort 



For example, consider the history in Figure [[} Here the very fact that the incomplete operation 
Ti read the "new" (written by T3) value in object x and the "old" (initial) value in object y 
prevents an updating transaction T\ from committing. Suppose that Ti commits. Then T2 can 
only be serialized (put in the global sequential order) after T3 and before Ti, while Ti can only 
be serialized before T3. Thus, we obtain a cycle which prevents any serialization. Therefore, the 
history does not provide non-interference: by removing T2 we can commit Ti by still allowing a 
correct serialization Ti, T3. But the history is permissive with respect to opacity: no transaction 
aborts without a reason! 

This example can be used to show that non-interference, when applied to opacity, is, in a strict 
sense, non-implementable. Every opaque permissive implementation that guarantees that every 
transactional operation {read, write, tryCommit or tryAbort) completes if it runs in the absence of 
concurrency (note that it can complete with an abort response), may be brought to the scenario 
above, where the only option for Ti in its last event is abort. 

Local correctness. But are there relaxed definitions of TM correctness that allow for non-interfering 
implementations? Intuitively, the problem with the history in Figure [T] is that T2 should be con- 
sistent with a global order of all transactions. But what if we only expect every transaction to be 
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locally consistent with the transactions that committed before it terminates? This way a transac- 
tion does not have to account for transactions that are aborted or incomplete at the moment it 
completes. 

For example, the history in Figure [TJ assuming that T\ commits, is still locally opaque: the 
local serialization of T<i would simply be T3 • T2, while T\ (assuming it commits) and T3 would both 
be consistent with the serialization T\ ■ T3. 

In this paper, we introduce the notion of local correctness. Informally, a history satisfies a local 
correctness property P if and only if all its "local sub-histories" satisfy P. Here a local sub-history 
corresponding to T, consists of the events of Tj and all transactions that committed before the 
last event of Tj (transactions that are incomplete or aborted at that moment are ignored). We 
show that every permissive, with respect to a local correctness criterion P, implementation is also 
non-interfering with respect to P. 

Virtual world consistency (7l, that expects the history to be strictly serializable and every 
transaction to be consistent with its causal past, is one example of a local correctness property. 
We observe, however, that virtual world consistency may allow a transaction to proceed even if 
it has no chances to commit. To avoid this, we introduce a stronger local criterion that we call 
local opacity. As the name suggests, a history is locally opaque if each of its local sub-histories is 
opaque. In contrast with VWC, a locally opaque history, a transaction may only make progress if 
it still has a chance to be committed. 

Implementing conflict local opacity. Finally, we describe a novel TM implementation that is permis- 
sive (and, thus, non-interfering) with respect to conflict local opacity (CLO). CLO is a restriction 
of local opacity that additionally requires each local serialization to be consistent with the conflict 
order j6, 10 



Our implementation is interesting in its own right for the following reasons. First, it ensures non- 
interference, i.e., no transaction has any effect on other transactions before committing. Second, 
it only requires polynomial (in the number of concurrent transactions) local computation for each 
transaction. Indeed, there are indications that, in general, building a permissive strictly serializable 
TM may incur non-polynomial time |10| . 

Roadmap. The paper is organized as follows. We describe our system model in Section [2} In 
Section [3] we formally define the notion of non-interference, recall the definition of permissiveness, 
and relate the two. In Section |4j we introduce the notion of local correctness, show that any 
permissive implementation of a local correctness criterion is also permissive, and define the criterion 
of conflict local opacity (CLO). In Section [5] present our non- interfering CLO implementation. 
Section [6] concludes the paper with remarks on the related work and open questions. 



2 System Model and Preliminaries 

We assume a system of n processes, pi, ■ . . ,p n that access a collection of objects via atomic transac- 
tions. The processes are provided with four transactional operations: the write (x, v) operation that 
updates object x with value v, the read(x) operation that returns a value read in x, tryCQ that 
tries to commit the transaction and returns commit (c for short) or abort (a for short), and tryAQ 
that aborts the transaction and returns A. The objects accessed by the read and write operations 
are called as t-objects. For the sake of presentation simplicity, we assume that the values written 
by all the transactions are unique. 
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Operations write, read and tryCQ may return a, in which case we say that the operations 
forcefully abort. Otherwise, we say that the operation has successfully executed. Each operation 
is equipped with a unique transaction identifier. A transaction T, starts with the first operation 
and completes when any of its operations returns a or c. Abort and commit operations are called 
terminal operations. For a transaction T^, we denote all its read operations as Rset(T k ) and write 
operations Wset(T k ). Collectively, we denote all the operations of a transaction Tj as evts(T k ). 

Histories. A history is a sequence of events, i.e., a sequence of invocations and responses of transac- 
tional operations. The collection of events is denoted as evts(H). For simplicity, we only consider 
sequential histories here: the invocation of each transactional operation is immediately followed by 
a matching response. Therefore, we treat each transactional operation as one atomic event, and let 
<H denote the total order on the transactional operations incurred by H. With this assumption 
the only relevant events of a transaction T k are of the types: r^ix, v), rk(x, A), Wk(x, v), Wk(x, v, A), 
tryC k {C) (or c k for short), tryC k (A), tryA k (A) (or a k for short). We identify a history H as tuple 
(evts{H),< H ). 

Let H\T denote the history consisting of events of T in H , and H\pi denote the history consisting 
of events of pi in H. We only consider well-formed histories here, i.e., (1) each H\T consists of 
a read-only prefix (consisting of read operations only), followed by a write-only part (consisting 
of write operations only), possibly completed with a tryC or try A operatiorj^J and (2) each H\pi 
consists of a sequence of transactions, where no new transaction begins before the last transaction 
completes (commits or a aborts). 

We assume that every history has an initial committed transaction Tq that initializes all the 
data-objects with 0. The set of transactions that appear in H is denoted by txns(H). The set 
of committed (resp., aborted) transactions in H is denoted by committed(H) (resp., aborted(H)). 
The set of incomplete transactions in H is denoted by incomplete(H) (incomplete(H) = txns(H) — 
committed(H) — aborted(H)). 

For a history H, we construct the completion of H, denoted H, by inserting a k immediately 
after the last event of every transaction T k E incomplete(H) . 

Transaction orders. For two transactions T k ,T m £ txns(H), we say that T k precedes T m in the 
real-time order of H, denote T k -if^ T m , if T k is complete in H and the last event of T k precedes 
the first event of T m in H. If neither T k T m nor T m T k , then T k and T m overlap in H. A 
history H is t-sequential if there are no overlapping transactions in H, i.e., every two transactions 
are related by the real-time order. 

Sub-histories. A sub-history, SH of a history H denoted as the tuple (evts(SH), <sh) and is 
defined as: (1) <sh ( Z<h', (2) evts(SH) C evts(H); (3) If an event of a transaction T k txns{H) is 
in SH then all the events of T k in H should also be in SH. For a history H, let R be a subset of 
txns(H), the transactions in H. Then H.subhist(R) denotes the sub- history of H that is formed 
from the operations in R. 

Valid and legal histories. Let H be a history and r k (x,v) be a read operation in H. A successful 
read r k {x,v) (i.e v ^ A), is said to be valid if there is a transaction Tj in H that commits before 
rx and Wj(x,v) is in evts(Tj). Formally, (r k (x,v) is valid =>• 3Tj : (cj <h r k (x,v)) A (w,j(x,v) G 
evts(Tj)) A (v A)}. The history H is valid if all its successful read operations are valid. 

We define r k (x,v)'s lastWrite as the latest commit event Cj such that q precedes r k (x,v) in H 
and x G Wset(Ti) (Tj can also be To). A successful read operation r k (x,v) (i.e v ^ A), is said to 

a This restriction brings no loss of generality |9|. 
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be legal if transaction Tj (which contains r^'s last Write) also writes v onto x. Formally, (rk(x,v) 
is legal => (v ^= A) A (H.lastWrite(ri~(x,v)) = Cj) A (wi(x,v) E evts(Ti))). The history if is legal if 
all its successful read operations are legal. Thus from the definitions we get that if H is legal then 
it is also valid. 

Strict Serializability and Opacity. We say that two histories H and H' are equivalent if they have 
the same set of events. Now a history H is said to be opaque [4,5] if is valid and there exists a t- 
sequential legal history S such that (1) S is equivalent to H and (2) S respects <^ , i.e <^ <Z<^ T . 
By requiring S being equivalent to H, opacity treats all the incomplete transactions as aborted. 

Along the same lines, a valid history H is said to be strictly serializable if H .subhist(committed{H)) 
is opaque. Thus, unlike opacity, strict serializability does not include aborted transactions in the 
global serialization order. 



3 Non-interference 

A correctness criterion is a set of histories. In this section, we recall the notion of permisiveness [3] 
and then we formally define non-interference. First, we define a few auxiliary notions. 

For a transaction Tj in H, H Ti denotes the shortest prefix of H containing all events of Tj in 
H. Now for Ti E aborted(H), let T-L Ti,c denote the set of histories constructed from H Ti , where 
the last operation of Tj in H is replaced with (1) ri(x,v) for some value non-abort value v, if the 
last operation is rj(x, ^4), (2) Wi(x, v, A), if the last operation is Wi(x, v, A), (3) tryC^C), if the last 
operation is tryC^A). 

If R is a subset of transactions of txns(H), then H_r denotes the sub-history obtained after 
removing all the events of R from H. Respectively, denotes the set of histories in % *' with 

all the events of transaction in R removed. 

Finally, IncAbort(H,T) denotes the set of transactions that are aborted or incomplete in H T . 

Definition 1 Given a correctness criterion P, we say that a history H is permissive with respect 
to P, and we write H E Perm(P) if: 

(1) H E P; 

(2) VT E Abort(H), VH' E U Tfi : H' £ P. 

From this definition we can see that a history H is permissive w.r.t. P, if no aborted transaction 
in H can be turned into committed, while preserving P. 

The notion of non-interference or iVJ(P) is defined in a similar manner as a set of histories 
parameterized by a property P. For a transaction T in txns(H), IncAbort(T, H) denotes the set of 
transactions that have (1) either aborted before T's terminal operation or (2) are incomplete when 
T aborted. Hence, for any T, IncAbort(T, H) is a subset of aborted(H) U incomplete(H) . 

Definition 2 Given a correctness criterion P, we say that a history H is non-interfering with 
respect to P, and we write H E NI(P) if: 

(1) H E P; 

(2) VT E Abort(H), R C IncAbort(T, H), VH' E H' £ P. 
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Informally, non-interference states that none of transactions that aborted prior to or are live at 
the moment when T aborts caused T to abort: removing any subset of these transactions from 
the history does not help t to commit. By considering the sepcial case R = in Definition § we 
obtain Definition [TJ and, thus: 

Observation 1 For every correctness criterion P, NI{P) C Perm(P). 

The example in Figure [l] (Section [I]) shows that Nl(opacity) ^ Perm(opacity) and, thus, no imple- 
mentation of opacity can satisfy non-interference. This motivated us to define a new correctness 
criterion, a relaxation of opacity, which satisfies non-interference. 

4 Local correctness and non-interference 

Intuitively, a correctness criterion is local if is enough to ensure that, for every transaction, the 
corresponding local sub-history is correct. One feature of local properties is that their permissive 
implementations ensure non-interference. 

Formally, for Tj in txns(H), let subC(H,Ti) denote 

H T \subhist(committed(H Tl ) U {Ti}), 

i.e., the sub- history of H Ti consisting of the events of all committed transactions in H Ti and T, 
itself. 

Definition 3 A correctness criterion P is local if for all histories H: 
H G P if and only if , for all T G txns(H), subC(H,Ti) G P. 

As we show in this section, one example of a local property is virtual world consistency [7] . Then we 
will introduce another local property that we call conflict local opacity (CLO), in the next section, 
describe a simple permissive CLO implementation. 

4.1 Local correctness and non-interference 

Theorem 2 For every local correctness property P, Perm(P) C NI(P) . 

Proof. We proceed by contradiction. Assume that H is in Perm(P) but not in NI(P). More 
precisely, let T a be an aborted transaction in H, R C IncAbort(T a , H) and H G , such that 

H G P. 

On the other hand, since H G Perm(P), we have 'H Ta,c n P = 0. Since P is local and H G P, 
we have VTj G txns(P), subC(H,Ti) G P. Thus, for all transactions Tj that committed before the 
last event of T a , we have subC(H,Ti) = subC{H Ta ,Ti) G P. 

Now we construct H as H Ta , except that the aborted operation of T a is replaced with the last 
operation of T a in H. Since H is in P, and P is local, we have subC(H ,T a ) = subC(H ,T a ) G P. 
For all transactions Ti that committed before the last event of T a in H, we have subC{H ,T) = 
subC(H Ta ,Ti) G P. Hence, since P is local, we have H G P. But, by construction, H G H Ta ' C — a 
contradiction with the assumption that % Ta)C n P = 0. □ 

As we observed earlier, for any correctness criterion P, NI(P) C Perm(P). Hence, Theorem [2] 
implies that for any local correctness criterion P NI(P) = Perm(P). 
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4.2 Virtual world consistency 

The correctness criterion of virtual world consistency (VWC) [7| relaxes opacity by allowing aborted 
transactions to be only consistent with its local causal past. More precisely, we say that T causally 
precedes Tj in a history H, and we write Ti -<g p Tj if one of the following conditions hold (1) Tj 
and Tj are executed by the same process and Tj Tj, (2) T commits and Tj reads the value 
written by Tj to some object x G WsetiTi) n Rset(Tj) (recall that we assumed for simplicity that all 
written values are unique), or (3) there exists T*., such that T -<^ p T& and T& -<^ p Tj. The set of 
transactions T such that T, -<^r P Tj and T,- itself is called the causal past of Tj, denoted CP(Tj). 

Now H is in VWC if (1) H.subhist(committed) is opaque and (2) for every T 6 txns(H), 
H .subhist(C P(Tj)) is opaque. Informally, -ff must be strictly serializable and the causal past of 
every transaction in H must constitute an opaque history. 

It is easy to see that H £ VWC if and only if for all subC(H,Ti) G VWC. By Lemma [2j any 
permissive implementation of VWC is also non-interfering. 



4.3 Conflict local opacity 

As shown in [7], the VWC criterion may allow a transaction to proceed if it is "doomed" to abort: 
as long as the transaction's causal past can be properly serialized, the transaction may continue if 
it is no more consistent with the global serial order and, thus, will have to eventually abort. We 
propose below a stronger local property that, intuitively, aborts a transaction as soon as it cannot 
be put in a global serialization order. 

Definition 4 A history H is said to be locally opaque or LO ; if for each transaction T in H : 
subC(H,Ti) is opaque. 

It is immediate from the definition that a locally opaque history is strictly serializable: simply 
take Tj above to be the last transaction to commit in H. The resulting subC(H,Ti) is going to 
be H .subhist(committed(H)) , the sub-history consisting of all committed transactions in H. Also, 
one can easily see that local opacity is indeed a local property. 

Every opaque history is also locally opaque, but not vice versa. To see this, consider the history 
H in Figure [2] which is like the history in Figure [TJ except that transaction T\ is now committed. 
Notice that the history is not opaque anymore: Tl, Ti and T3 form a cycle that prevents any 
legal serialization. But it is locally opaque: each transaction witnesses a state which is consistent 
with some legal total order on transactions committed so far: subC{H,T\) is equivalent to T3T1, 
subC(H,T2) is equivalent to T3T2, subC{H,T^) is equivalent to T3. 



Ti c 
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Figure 2: A locally opaque, but not opaque history (the initial value for each object is 0) 
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We denote the set of locally opaque histories by LO. Finally, we propose a restriction of local 
opacity that ensures that every local serialization respects the conflict order |12| Chap. 3]. For 
two transactions T k and T m in txns(H), we say that T k precedes T m in conflict order, denoted 
T k -<h° T m, if (w-w order) tryC k (C) < H tryC m {C) and Wset(T k ) n Wset(T m ) ^ 0, (w-r order) 
tryC k {C) <h r m (x,v), x G Wset(T k ) and v ^ A, or (r-w order) r k (x,v) <h tryC m (C), x E 
Wset(T m ) and v ^ A. Thus, it can be seen that the conflict order is defined only on operations 
that have successfully executed. Using conflict order, we define a subclass of opacity, conflict opacity 
(co-opacity). 

Definition 5 A history H is said to be conflict opaque or co-opaque if H is valid and there exists 
a t-sequential legal history S such that (1) S is equivalent to H and (2) S respects and -<§ C '• 

Now we define a "conflict" restriction of local opacity, conflict local opacity (CLO) by replacing 
opaque with co-opaque in Definition [4} Immediately, we derive that co-opacity is a subset of opacity 
and CLO is a subset of LO. 

5 Implementing Local Opacity 

In this section, we present our permissive implementation of CLO. By Lemma [2] it is also non- 
interfering. Our implementation is based on conflict-graph construction of co-opacity, a popular 
technique borrowed from databases (cf. [l2j Chap. 3]). We then describe a simple garbage-collection 
optimization that prevents the memory used by the algorithm from growing without bound. 

5.1 Graph characterization of co-opacity 

Given a history H, we construct a conflict graph, CG(H) = (V,E) as follows: (1) V = txns(H), 
the set of transactions in H (2) an edge (Ti,Tj) is added to E whenever Tj Tj or Tj -<jj Tj, 
i.e., whenever Tj precedes Tj in the real-time or conflict order. 

Note, since txns(H) = txns{H) and (^g T U ^g°) = U ^°), we have CG(H) = 

CG(H). In the following lemmas, we show that the graph characterization indeed helps us verify 
the membership in co-opacity. 



Lemma 3 Consider two histories HI and H2 such that HI is equivalent to H2 and HI respects 
conflict order of H2, i.e., ^m^H®- Then, -<g^=-<^. 



Proof. Here, we have that ■^ ( hi—^ ( H2- ^ n or der to prove -< < ui = < < H2, we have to show that 
~< < H2 < ^^ < hi- We prove this using contradiction. Consider two events p, q belonging to transaction 
T1,T2 respectively in H2 such that (p, q) but (p, q) ^< < ^. Since the events of H2 and HI 

are same, these events are also in HI. This implies that the events p, q are also related by CO in 
HI. Thus, we have that either (p, q) or (q,p) But from our assumption, we get that 

the former is not possible. Hence, we get that (q,p) G^q=> (q,p) ^^H2- we a l rea dy have 
that (p,q) e^H°. This is a contradiction. □ 



Lemma 4 Let HI and H2 be equivalent histories such that ~< < hi = ^ ( h2 ■ Then HI is legal iff H2 
is legal. 
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Proof. It is enough to prove the 'if case, and the 'only if case will follow from symmetry of the 
argument. Suppose that HI is legal. By contradiction, assume that H2 is not legal, i.e., there is 
a read operation rj(x,v) (of transaction Tj) in H2 with last Write as c/% (of transaction Tj.) and T^ 
writes u ^ v to x, i.e Wk(x,u) £ evts(Tk). Let rj(x,v)'s last Write in HI be Cj of T. Since HI is 
legal, Ti writes v to x, i.e Wi(x,v) S evts(Ti). 

Since evts(Hl) = evts(H2), we get that q is also in H2, and is also in HI. As -^iil = ^ ( H2i 
we get Q <H2 rj(x,v) and c fc <#i rj(x,v). 

Since Cj is the last Write of rj(x,v) in i71 we derive that c& </n c, and, thus, <_ff2 Q <_ff2 
rj(x,v). But this contradicts the assumption that is the last Write of rj(x,v) in H2. Hence, H2 
is legal. □ 

From the above lemma we get the following interesting corollary. 
Corollary 5 Every co- opaque history H is legal as well. 

Based on the conflict graph construction, we have the following graph characterization for co- 
opaque. 

Theorem 6 A legal history H is co-opaque iff CG(H) is acyclic. 
Proof. 

(Only if) If H is co-opaque and legal, then CG(H) is acyclic: Since H is co-opaque, there exists a 
legal t-sequential history S equivalent to H and S respects and -<h°- Thus from the conflict 
graph construction we have that CG(H)(= CG(H)) is a sub graph of CG(S). Since S is sequential, 
it can be inferred that CG(S) is acyclic. Any sub graph of an acyclic graph is also acyclic. Hence 
CG(H) is also acyclic. 

(if) If H is legal and CG(H) is acyclic then H is co-opaque: Suppose that CG(H) = CG(H) is 
acyclic. Thus we can perform a topological sort on the vertices of the graph and obtain a sequential 
order. Using this order, we can obtain a sequential schedule S that is equivalent to H . Moreover, 
by construction, S respects -< I h^=<j^ and ^h° = ^§°- 

Since every two events related by the conflict relation (w-w, r-w, or w-r)in 5 are also related by 
-<^°, we obtain -<5°=^°. Since H is legal, H is also legal. Combining this with Lemma jij we 
get that S is also legal. This satisfies all the conditions necessary for H to be co-opaque. □ 



5.2 The Algorithm for Implementing CLO 

Our CLO implementations is presented in Algorithms [TJ [2] and [3] (we omit the trivial implementation 
of try A here). The main idea is that the system maintains a sub- history of all the committed 
transactions. Whenever a live transaction Tj wishes to perform an operation Oi (read, write or 
commit), the TM system checks to see if Oj and the transactions that committed before it, form a 
cycle. If so, o% is not permitted to execute and Tj is aborted. Otherwise, the operation is allowed to 
execute. Similar algorithm(s) called as serialization graph testing have been proposed for databases 
(cf. [TJJ Chap. 4]). Hence, we call it SGT algorithm. 

Our SGT algorithm maintains several variables. Some of them are global to all transactions 
which are prefixed with the letter 'g'. The remaining variables are local. The variables are: 
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Algorithm 1 Read of a t-object x by a transaction Tj 
1: procedure readi(x) 
2: // read gComHist 
3: tHisti = gComHist; 
4: // create v, to store a the value of x 
5: f = the latest value written to x in tHisti] 
6: // create Iseqi, the local copy of gseqn 

7: Zsegj = the value of largest seq. no. of a transaction in IComHisti; 
8: create the readVar ropi(x,v, Iseq^; 
9: // update IComHisti 

10: IComHisti = merge IComHisti and tHisti; append ropi(x,v, Iseq^ to IComHisti; 
11: / / Check for consistency of the read operation 
12: if (CG (IComHisti) is cyclic) then 

13: replace ropi(x,v, Iseq^ with (ropi(x,A, lseq,j) in IComHisti); 

14: return abort; 

15: end if 

16: // Current read is consistent; hence store it in the read set and return v 

17: return v; 

18: end procedure 



Algorithm 2 Write of a t-object x with value v by a transaction Tj 
1: procedure writei(x, v) 

2: if writei(x,v) is the first operation in Tj then 
3: // read gComHist 

4: IComHisti = gComHist; 

5: /se^j = the value of largest seq. no. of a transaction in IComHisti; 

6: end if 

7: create the writeVar wopi(x,v, kegj; 
8: append wopi(x,v, lseq,j) to IComHisU; 
9: return ofc; 
10: end procedure 
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Algorithm 3 TryCommit operation by a transaction Tj 
1: procedure tryC i 

2: lock gLock; 

3: // create the next version of gseqn for the current Tj 

4: kegj = gSeqNum + 1; 

5: tffoij = gComHist; // create a local copy of gComHist 

6: IComHisti = merge IComHisti and tHisti; / / update IComHisti 

7: // Create the commit operation with lseq i 

8: create the comVar cop^lseq^); 

9: append cop^lseq^) to IComHisti; 

10: if (CG (IComHisti) is cyclic) then 
11: Replace copi(lseq,j) with ctj in IComHisti] 

12: Release the lock on gLock; 

13: return abort; 

14: end if 

15: gComHist = IComHisti; 

16: gSeqNum = Iseqf, 

17: Release the lock on gLock; 

18: return commit; 

19: end procedure 



• gSeqNum, initialized to in the start of the system: global variable that counts the number 
of transactions committed so far. 

• lseqi'. a transaction-specific variable that contains the number of transactions currently ob- 
served committed by T; L . When a transaction T; L commits, the current value of gSeqNum is 
incremented and assigned to Iseq^ 

• readVar: captures a read operation performed by a transaction Tj. It stores the variable x, 
the value v returned by r\ and the sequence number s of ri, computed as the sequence number 
of the committed transaction ri reads from. We use the notation ropi(x,v, s) to denote the 
read operation in the local or global history. 

• writeVar: captures a write operation Wi(x,v) performed by a transaction T, t . It stores the 
variable x, the value written by the write operation v and the sequence number s of 
computed as the sequence number of the previous op in T« or the sequence number of the 
last committed transaction preceding Tj if Wi is the first operation in Tj. We use the notation 
wopi(x,v, s) to denote the writeVar operation. 

• comVar: captures a commit operation of a transaction Tj. It stores the feeg, of the transaction. 
We use the notation copi(s) to denote the comVar operation where s is the lseqi OI the 
transaction. 

• gComHist: captures the history of events of committed transactions. It is a list of readVar, 
writeVar, comVar variables ordered by real-time execution. We assume that gComHist also 
contains initial values for all t-variables (later updates of these initial values will be used for 
garbage collection). 
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• gLock: This is a global lock variable. The TM system locks this variable whenever it wishes 
to read and write to any global variable. 

The implementations of Tj's operations, denoted by readi(x), writei(x,v) and fn/QQ are de- 
scribed below. We assume here that if any of these is the first operation performed by Tj, it is 
preceded with the initialization all Tj's local variables. 

We also assume that all the t-objects accessed by the STM system is initialized with (which 
simulates the effect of having an initial transaction To). 

readi(x): The TM system creates IComHisti which is a local copy gComHist. From IComHisti the 
values, v, Iseqi, are computed. If there is no write operation on x, then v is assumed to be the 
initial value 0. Each read operation previously performed by Tj (if any) is inserted into IComHisti 
at appropriate location based on its readSeqNum. Then, a readVar ropi is created for the current 
read operation using the latest value of x, v and the current value of gSeqNum, Iseq^ Then ropi is 
inserted into IComHisti. A conflict graph is constructed from the resulting IComHisti and checked 
for acyclicity. If the graph is cyclic then A is inserted into ropi of IComHisti and then abort is 
returned. Otherwise, the value v is returned. 

writei(x,v): adds a writeVar containing x and v and Iseqi is inserted to IComHisti. (If the write 
is the first operation of Tj, then IComHisti and Iseqi are computed based on the current state of 
gComHisti.) 

tryCi{x): The main idea for this procedure is similar to readi, except that the TM system first 
obtains the lock on gLock. Then it makes local copies of gSeqNum, gComHist which are Iseqi, tHisti, 
and IComHisti. The value Iseqi * s incremented, and the copi(lseqi) item is appended to IComHisti. 
Then a conflict graph is constructed for the resulting IComHisti and checked for acyclicity. If the 
graph is cyclic then copi(seqi) is replaced with a% in IComHisti, the lock is released and abort is 
returned. Otherwise, Iseq^ IComHisti, are copied back into gSeqNum, gComHist, the lock is released 
and ok is returned. 

5.3 Correctness of SGT 

In this section, we will prove that our implementation is permissive w.r.t. CLO. Consider the 
history H generated by SGT algorithm. Recall that only read, tryC and write operation (if it is 
the first operation in a transaction) access shared memory. Hence, we call such operations memory 
operations. 

Note that H is not necessarily sequential: the transactional operations can execute in over- 
lapping manner. Therefore, to reason about correctness, we first order all the operations in H to 
get an equivalent sequential history. We then show that this sequential history is permissive with 
respect to CLO. 

We place the memory operations, say rj(x, v/A), tryCj(C/A) based on the order in which they 
access the global variable gComHist, storing the history of currently committed transactions. The 
remaining write operations are placed anywhere between the last preceding memory operation and 
its tryCi operation. We denote the resulting history, completed by adding tryC^A) operation for 
every incomplete transaction Tj, by H g . It can be seen that H g represents a complete sequential 
history that respects the real time ordering of memory operations in H. In the rest of this section, 
we show that H g is permissive (and, thus, non-interfering) with respect to CLO. 

Since CLO is local, to show that H g is in CLO, it is sufficient to show that, for each transaction 
Ti in txns(H g ), subC(H g ,Ti) is in CLO. We denote subC{H g ,Ti) by H ig . 
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Consider a transaction T G txns(H g ). Consider the last complete memory operation of T in H, 
denoted as m«. Note that every Tj performs at least one successful memory operation (the proof 
for the remaining case is trivial). We define a history Hi m as the local history IComHisti computed 
by SGT with the last complete memory operation of T in H (line 10 of Algorithm [lj and line [9] of 
Algorithm [3]) . 

Lemma 7 Hi m and Hi g are equivalent. 

Proof. Obviously, Hi m and Hi g agree on the events of Tj. The SGT algorithm assigns commitSe- 
qNum (a sequence number) to each committed transaction Tj . Similarly it also assigns readSeqNum 
to each successfully completed read operation, i.e. the read that did not return abort. Based on 
these sequence numbers, the SGT algorithm constructs H; im (line 10 of Algorithm [TJ and line [9] 



of Algorithm [3]) of all the events that committed before the last successful memory operation of 
T in H g . On the other hand, every event that appears in Hi m belongs to Tj or a transaction 
that committed before the last successful memory operation of T in H g . Thus, Hi m and Hi g are 
equivalent. □ 



Even though Hi m and H g are equivalent, the ordering of the events in these histories could be 
different. However, the two histories agree on the real-time and conflict orders of transactions. 

Lemma 8 -<£° =-<£° and <W~ =<W~ 

Proof. We go case by case for each possible relation in ~tp° U -< RT . 

Write-write order: we want to show that (tryC p <j m tryC q ) 44> (Tp.commitSeqNum < T q .commitSeqNur 
(tryC p < ig tryC q ). 

The result (tryC p <j m tryC q ) 44> {Tp.commitSeqNum < T q . commits eqNum) follows from the 
construction of Hi m . We have already shown earlier that tryC operation is atomic. When a 
transaction T successfully commits in the SGT algorithm, it is assigned an unique commitSe- 
qNum which is monotonically increasing. As a result, a tryC operation which commits later gets 
higher commits eqNum in H g . Since the ordering of events in H g are same as Hi g , we get that 
(Tp.commitSeqNum < T q . commits eqNum) 4=> (tryC p <i g tryC q ). 

Write-read order: For a committed transactions T p and a successful read operation r q , we want to 
show that [tryCp <i m r q ) 44> (Tp.commitSeqNum < r q . readSeqNum) 43- (tryC p <, ig r q ). 

The result (tryC p <i m r q ) 44> (Tp.commitSeqNum < r q . readSeqNum) follows from the construc- 
tion of Hi m . The SGT algorithm stores as a part of the read operation rj, readSeqNum which 
is same as the commitSeqNum of the latest transaction that committed before rj, say Tj. Thus 
Ti. commits eqNum = rj .readSeqNum. From the above argument for the write-write order, we have 
that any transaction Tk that committed before Tj will have lower commitSeqNum. This holds in 
H g and as a result also holds in Hi g . This shows that (Tp.commitSeqNum < r q . readSeqNum) 44> 
(tryCp < ig r q ). 

Read-write order: For a committed transactions T q and a successful read operation r p , we want 
to show that (r p <j m tryC q ) 44> (r p . readSeqNum < T q . commitSeqNum) 44> (r p <i g tryC q ). The 
reasoning is similar to the above cases. 
Hence, < C H ° =< C H ° ■ 

Real-time order: Consider two transaction T p , T q in Hi g such that T p -<f^ T q which also holds in 
H g . From the construction of Hi g , we get that T p is a committed transaction with its last event 
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being tryC p . Indeed, the only possibly uncommitted transaction in Hi g is Tj that performs the last 
event in Hi g and, thus, cannot precede any transaction in -<^: . 

Consider the first memory operation of T q (by our assumption, there is one in each T q in Hi g ). 
By the algorithm, the sequence number associated with the memory operation is at least as high 
as the sequence number of tryC p . Thus T p -«<§ T T q The other direction is analogous. 

/ FLT i RT^ 

^r^ — ~S tt 

H i.m fli 



Hence, <W =<W ■ □ 



Lemmas [7] and [8] imply that Hi m and Hi g generate the same conflict graph: 
Corollary 9 CG(H ig ) = CG{H ig ) 

Now we argue about legality of Hi m and Hi g . 
Lemma 10 Hi g is legal. 

Proof. By the algorithm, every successful read operation on a variable x within Tj returns the 
argument of the last committed write on x that appears in IComHisti (and, thus, in Hi m ). By 
applying this argument to every prefix of Hi m , we derive that Hi m is legal. By Lemmas [4] and |8j 
we derive that Hi g is also legal. □ 



Theorem 11 Let H g be a history generated by the SGT algorithm. Then H g is in CLO. 

Proof. By the algorithm, the corresponding iJj m produces an acyclic conflict graph CG{Hi m ) (cf. 
checks in line 12 of Algorithm [T] and line 10 of Algorithm [3]) . By Corollary [9j CG(Hi m ) is also 



acyclic. 

Thus, by Theorem [6] and Lemma 10, for every Tj S txns(H g ), Hi g is co-opaque. Since CLO is 



a local property, we derive that H g is in CLO. □ 

Having proved that SGT algorithm generates CLO histories, we now show that SGT algorithm 
is in fact permissive w.r.t. CLO. 

Theorem 12 Let H g be a history generated by SGT algorithm. Then H g is in Perm(CLO) . 

Proof. We shall prove this by contradiction. Assume that H g is not in Perm(CLO). From 
Theorem 11, we get that H g is in CLO. Hence, condition (2) of Definition [TJ is not true. Thus, 
there is an aborted transaction T a in H g which can be committed so that the resulting history is 
still in CLO. We denote the modified transaction as T^ and the resulting history as H' g . There are 
two cases depending on the final event of T a : 

Case 1: The last event of T a is a read operation r a (x,A). In order for T^ to be committed 
in H' g , r a (x,A) is converted to r a (x,v) for some v. If H' g is in CLO, then subC(H' g ,T^) is co- 
opaque. By Corollary [5J we get that subC(H' g ,T^) is legal. Therefore, v is the value written by 
the transaction committing r a 's last Write in H' g (the current value on v). It can be seen that H' g 
differs from H g only in r a . 

But when SGT algorithm attempts to read this value of x in line 10 of Algorithm [TJ it causes 



the conflict graph maintained to be cyclic. From Corollary [9] applied to H' a , we get that the conflict 
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graph maintained to be cyclic. By Corollary 
subC(H'T^) is also cyclic. From Theorem 



graph of subC(H' g , T^) is also cyclic. By TheoremjfjJ we derive that subC(H' g , T^) is not co-opaque. 
This implies that H' g is not in CLO — a contradiction. 

Case 2: The last event of T a is an abort operation tryC a (A). The argument in this case is similar 
to the above case. In order for T~ to be committed in H' g , tryC a (A) is converted into tryC a {C). 
When SGT algorithm attempts to commit T a in line [9] of Algorithm [3j it causes the conflict 

applied to H' g , we derive that the conflict graph of 
6, we then get that subC(H' g ,T^) is not co-opaque. 
This implies that H' g is not in CLO and hence again a contradiction. 

Therefore, no transaction T a in H g can not be transformed into a committed transaction 
while still staying in CLO. Hence, H g is in Perm(CLO). □ 

It is left to show that our algorithm is live, i.e., under certain conditions, every operation eventually 
completes. 

Theorem 13 Assuming that no transaction fails while executing the tryC operation and gLock is 
starvation-free, every operation of SGT eventually returns. 

Proof. It can be seen that read and write functions do not involve any waiting. Therefore, tryC is 
the only function which involves waiting for the gLock variable. But since the lock is starvation-free 
and no transaction executing tryC obtains the lock forever, every such waiting is finite. Thus, every 
tryC operation eventually grabs the lock and, after, computing the outcome, returns. □ 



5.4 Garbage Collection 

Over time, the history of committed transactions maintained by our SGT algorithm in the global 
variable gComHist grows without bound. We now describe a simple garbage-collection scheme that 
allows to keep the size of gComHist proportional to the current contention, i.e, to the number of 
concurrently live transactions. The idea is to periodically remove from gComHist the sub-histories 
corresponding to committed transactions that become obsolete, i.e., the effect of them can be 
reduced to the updates of t-objects. 

More precisely, a transaction Tj's UveSet is the set of the transactions that were incomplete 
when Ti terminated. A t-complete transaction Tj is said to be obsolete (in a history H) if all the 
transactions in its liveSet have terminated (in H). 

To make sure that obsolete transactions can be correctly identified based on the global history 
gComHist, we update our algorithm as follows. When a transaction performs its first operation, it 
grabs the lock on gComHist and inserts the operation in it. Note that, as long as the transaction 
is not committed, this operation is not going to affect the acyclicity of the conflict graph for any 
local history IComHisti (it is not going to have outgoing edges). 

Now when a transaction commits it takes care of all committed transactions in gComHist which 
have become obsolete. All read operations preceding the last event of an obsolete transaction are 
removed, In case there are multiple obsolete transactions writing to the same t-object, only the 
writes of the last such obsolete transaction to commit are kept in the history. If an obsolete 
transaction is not the latest to commit an update on any t-object, all events of this transactions 
are removed. 
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In other words, Hi m defined as the local history IComHisti computed by SGT within the last 



complete memory operation of Tj in the updated algorithm (which corresponds to line 10 of Al- 
gorithm [I] and line [9] of Algorithm [3]) preserves write and commit events of the latest obsolete 
transaction to commit a value for every t-object. All other events of other obsolete transactions 



are removed. The computed history Hi m is written back to gComHist in line 15 of Algorithm [TJ 



Let this gComHist be used by a transaction Tj in checking the correctness of the current local 
history (line 12 of Algorithm [T] or line 10 of Algorithm [3]). Recall that Hi g denotes the corresponding 
local history of Tj. Let Tg be any obsolete transaction in Hi g . Note that all transactions that 
committed before Tg in Hi g are also obsolete in Hi g , and let U denote the set of all these obsolete 
transactions, including Tg. Respectively, let obs(Hi g , U) be a prefix of Hi g in which all transactions 
in UveSetQ Also, let trim(Hi g , U) be the "trimmed" local history of Tj where all transactions in U 
are removed or replaced with committed updates, as described above. 

Lemma 14 Hi g is in CLO if and only if obs(Hi g , U) and trim(Hi g , U) are in CLO. 

Proof. (Only if) Suppose that Hi g is in CLO. By Corollary [5j Hi g is legal. Since obs(Hi g ,U) is 
a prefix of H{ g , it is also legal, and its conflict graph is a sub-graph of CG{Hi g . By Theorem |6j 
CG(obs(Hi g ,U)) is acyclic and, thus, obs(Hi g ,U) is in CLO. 

Further, let rj.[x, v) be any read operation in trim(Hi g ,U). Since Hi g is legal, ri~(x, v) is also 
legal. Note that since no read operation of obsolete transactions in Hi g appears in trim(Hi g ,U), 
Tfc is not in TJ. Let c m be rk(x,v) 's lastWrite in Hi g . If c m appears in trim(Hi g ,U), then 
c m is also rfc(x,f) 's lastWrite in trim(Hi g ,U), and, thus, Tk(x,v) is also legal. Now, suppose, by 
contradiction, that c m does not appear in trim(Hi g , U), i.e., c m is not the last (obsolete) transaction 
in U to commit a value on x, i.e., there exists a transaction T s £ U writing to x such that c s appears 
after c m in Hi g . Since c m is rk(x,v) 's lastWrite in Hi g , c s appears after rk(x,v) in Hi g . But T s 
is obsolete, and, thus, no read operation can appear before c s in trim(Hi g ,U) — a contradiction. 
Thus, c m is rk(x,v) 's lastWrite in trim(Hi g ,U), and, hence, trim{Hi g ,U) is legal. 

Since trim(Hi g , U) is a legal sub-sequence of Hi g , CG(trim(Hi g , U)) is a sub-graph of CG{H; Lg ) 
and, by Theorem[6j CG(trim(Hi g ,U)) is acyclic and trim(Hi g ,U) is in CLO. 
(If) Suppose now that obs(Hi g ,U) and trim(Hi g ,U) are in CLO. By Corollary [5j both histories 
are legal, and, by Theorem [6j produce acyclic conflict graphs. Immediately, every read operation 
in Hi g that also appears in obs(Hi g , U) is legal. By the arguments above, the lastWrite for every 
read operation in trim(Hi g , U) is also its lastWrite in Hi g . Thus, Hi g is legal. 

By the construction of obs(Hi g , U) and trim(Hi g , U), CG(Hi g ) is a graph composed of CG{obs{H,i g , 
and CG(trim(Hi g ,U)), with possibly some edges connecting vertices of the two graphs. More- 
over, no transaction where no new edge is directed from a vertex of CG(trim(Hi g , U)) to a 
vertex of CG(obs(Hi g ,U)). Indeed, all commit events of transactions of txns(trim(Hi g , U)) — 
txns(obs(Hi g , U)) appear after the last event of an obsolete transaction in U and thus cannot have 
outgoing edges joining a vertex to U. Thus, CG(Hi g is acyclic and, by Theorem[6l Hi g is in CLO. □ 



We observe that, iteratively, for each Tj, all our earlier claims on the relation between the 
actual local history Hi g and the locally constructed history Hi m (Lemmas and |[ hold now for 



10, Theorem 11 and Theorem 
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the "trimmed" history trim(Hi g ,U) and H{ m . Therefore, Lemma 

derived from Lemmas [7] and [8] also hold true. Now by Lemma 14 Hi m is in CLO if and only if 
Hi g c is in CLO, and, any history H g generated by the updated algorithm with garbage collection 
is permissive (and, thus, non-interfering) with respect to CLO. 
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Note that removing obsolete transactions from gComHist essentially boils down to dropping a 
prefix of it that is not concurrent to any live transactions. As a result, the length of gComHist 
is 0(M + C), where M is the number of t-objects and C is the upper bound on the number of 
concurrent transactions. 



6 Concluding remarks 

In this paper, we formally defined the notion of non-interference in transactional memory, originally 
highlighted in . The notion grasps the intuition that aborted or incomplete transactions should 
not "cause" other transactions to abort. We observe that no opaque TM implementation can 
provide non-interference. However, we observed that any permissive implementation of a local 
correctness criterion is also non-interfering. Informally, showing that a history is locally correct is 
equivalent to showing that every its local sub- history is correct. We discussed two local criteria: 
virtual- world consistency (VWC) 7 and the (novel) local opacity (LO). Interestingly, unlike VWC, 
LO does not allow a transaction that is doomed to abort to waste system resources. 

We then considered CLO, a restriction of LO that, in addition, requires every local serialization 
to respect the conflict order [6 10 of the original sub- history. We presented a permissive, and 



thus non-interfering, CLO implementation. This appears to be the only non-trivial permissive 
implementation known so far (the VWC implementation in [2] is only probabilistically permissive). 

Our definitions and our implementation intend to build a "proof of concept" for non-interference 
and are, by intention, as simple as possible (but not simpler). Of course, interesting directions are 
to extend our definitions to (more realistic) non-sequential histories and to relax the strong ordering 
requirements in our correctness criteria. Indeed, the use of the conflict order allowed us to efficiently 
relate correctness of a given history to the absence of cycles in its graph characterization. This 
seems to make a lot of sense in permissive implementations, where efficient verification for strict 
serializability or opacity appear elusive |10| . 

Also, our implementation is quite simplistic in the sense that it uses one global lock to protect 
the history of committed transactions and, thus, it is not disjoint- access- parallel (DAP) fflM. An 
interesting challenge is to check if it is possible to construct a permissive DAP CLO implementation 
with invisible reads. 



References 

[1] H. Attiya, E. Hillel, and A. Milani. Inherent limitations on disjoint-access parallel imple- 
mentations of transactional memory. In Proceedings of the twenty-first annual symposium on 
Parallelism in algorithms and architectures, SPAA '09, pages 69-78, New York, NY, USA, 
2009. ACM. 

[2] T. Crain, D. Imbs, and M. Raynal. Read invisibility, virtual world consistency and probabilistic 
permissiveness are compatible. In LCA3PP (1), pages 244-257, 2011. 

[3] R. Guerraoui, T. Henzinger, and V. Singh. Permissiveness in transactional memories. In 
DISC '08: Proc. 22nd International Symposium on Distributed Computing, pages 305-319, 
sep 2008. Springer- Verlag Lecture Notes in Computer Science volume 5218. 



17 



[4] R. Guerraoui and M. Kapalka. On the correctness of transactional memory. In PPoPP '08: 
Proceedings of the 13th ACM SIGPLAN Symposium on Principles and practice of parallel 
programming, pages 175-184, New York, NY, USA, 2008. ACM. 

[5] R. Guerraoui and M. Kapalka. Principles of Transactional Memory, Synthesis Lectures on 
Distributed Computing Theory. Morgan and Claypool, 2010. 

[6] V. Hadzilacos. A theory of reliability in database systems. J. ACM, 35(1):121-145, Jan. 1988. 

[7] D. Imbs and M. Raynal. A versatile STM protocol with invisible read operations that satisfies 
the virtual world consistency condition. In Proceedings of the 1 6th international conference on 
Structural Information and Communication Complexity, SIROCCO'09, pages 266-280, Berlin, 
Heidelberg, 2010. Springer- Verlag. 

[8] A. Israeli and L. Rappoport. Disjoint-access-parallel implementations of strong shared memory 
primitives. In Proceedings of the thirteenth annual ACM symposium on Principles of distributed 
computing, PODC '94, pages 151-160, New York, NY, USA, 1994. ACM. 

[9] P. Kuznetsov and S. Ravi. On the cost of concurrency in transactional memory. In OPODIS, 
pages 112-127, 2011. 

[10] C. H. Papadimitriou. The serializability of concurrent database updates. J. ACM, 26(4):631- 
653, 1979. 

[11] S. Peri and K.Vidyasankar. An efficient scheduler for closed nested transactions that satisfies 
all- read-consistency and non-interference. In 13th International Conference on Distributed 
Computing and Networking, 2012. 

[12] G. Weikum and G. Vossen. Transactional Information Systems: Theory, Algorithms, and the 
Practice of Concurrency Control and Recovery. Morgan Kaufmann, 2002. 



18 



